docs(spec): map Agent Manifest onto SCITT terms (section 10.5) - #244
Merged
Conversation
"Agent-layer profile of SCITT" was a slogan with nothing behind it. This maps every structural piece of the spec to its RFC 9943 term: the agent is the Artifact, agent_id the Subject, the manifest the Statement, the signed manifest the Signed Statement, transparency_log_entry the Receipt, and a manifest with that field populated the Transparent Statement. The spec already mandates reaching that last state for production, so the correspondence is real rather than aspirational. The point of stating it is to tell an implementer which parts of this document are agent-specific (3.2 through 3.5, what it takes to describe an agent completely) and which are inherited and should be read as SCITT. Also names what the spec deliberately does not restate: OpenSSF Model Signing for the model artifact, SLSA and in-toto for build provenance, SCITT and Sigstore for transparency. Adds an OMS row to 10.4 and a v0.2 line item for an explicit OMS bundle reference in model_identity, so a verifier can follow the chain from agent to model publisher rather than trusting an operator-asserted hash. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes "agent-layer profile of SCITT" a checkable claim instead of a slogan. Follows #242, which settled the envelope.
New section 10.5
Every structural piece of this spec already has an RFC 9943 name. Stating the correspondence tells an implementer which parts are agent-specific and which are inherited:
agent_idissuertransparency_log_entryThe correspondence is real rather than aspirational: Section 3.6 already mandates reaching Transparent Statement for production ("the signature is NOT sufficient without the
transparency_log_entryfor regulatory purposes"). The agent-specific contribution is the Statement payload, sections 3.2 through 3.5, which is what it takes to describe an agent completely enough that a third party can tell whether the one running is the one approved. Everything around it should be read as SCITT rather than as a parallel invention.What the spec deliberately does not restate
model_identityto the deployed model; where a publisher ships an OMS bundle,model_hashshould be the digest OMS binds so the two agree by construction. Added as a 10.4 row, plus a v0.2 line item for an explicit bundle reference so a verifier can follow the chain from agent to model publisher rather than trusting an operator-asserted hash.supply_chain(3.2.8).Net effect is that adjacent efforts become dependencies rather than competitors, and the remaining gap is the one none of them covers: no existing standard binds a system prompt, policy bundle, tool catalog, memory baseline, delegation chain, and human approval into one hardware-attestable artifact.
Verification
SCITT terms and their definitions were taken from RFC 9943 itself, not from memory. Cross-references in the new section were checked against the spec (
supply_chainis 3.2.8 not 3.2.9; the section 3.6 transparency sentence quoted above exists at line 937).618 tests pass. No code in this PR.